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ABSTRACT 



Information stored in a corporate database is monitored and 
used to determine when certain business-related events have 
occurred. Event information is transmitted over the Internet 
to a print production facility, where it is used to fire one or 
more event rules, which in turn automatically generate print 
requisitions or print production orders. In one variation, 
print requisitions are routed through an existing and com- 
mercially available procurement system before a print pro- 
duction order is generated. The system can monitor and 
handle events from multiple corporations, each having its 
own business-related event rules, and each potentially hav- 
ing its own procurement approval system. 

14 Claims, 15 Drawing Sheets 
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APPARATUS FOR PRINTING a corporation or a new brochure is needed, the steps shown 

INFORMATION AUTOMATICALLY ^ FIG 1 must be carried out. Repeating these steps incurs 

COMBINED FROM TWO DIFFERENT extensive costs due to human involvement (e.g., labor costs) 

SOURCES ^ tne possibility that errors may be introduced into one or 

S more steps. Because of the many steps and human 

CROSS-REFERENCE TO RELATED involvement, a simple printing job can take days or even 

APPLICATION weeks * 

As one example, an employee's name must be typed or 

This application is a continuation and is related in subject printed on an order form, then transferred into an ordering 

matter to co-pending U.S. application Ser. No. 09/460,307 1Q computer, and manually entered again into a layout com- 

now pending, entitled "System and File Structure for Con- puter. Every time a human touches the information, the 

sistent Visual Medium Materials " which was filed on Dec. process is delayed and the possibility exists that an error will 

13, 1999. That application is incorporated by reference be introduced. Additionally, various validation and approval 

herein. procedures must be followed in order to ensure that the 

printed information will be produced correctly, and that only 

TECHNICAL FIELD certain authorized products are printed. 

„ . . „ , . . , . , Attempts to further automate the foregoing processes are 

This invention generally relates to systems that generate \ . , . c . 4 . • ♦ u i 

. L . , i U id / comp heated by the fact that different pnnt brokers may use 

printed products, such as general office stationery (e.g., * * * * u • j j / p 

i ** _i_ j l • j i \ ju* u j different formats, techniques, and software products for 

letterhead, business cards, or envelopes); and high-end mar- 4 . . ' "7 ' . . , j . j .t_ * . 

, A . ' A . ' . , , , ' j , . nn entering data and generating printed products, and the fact 

keting communication materials and other products that use 20 % & . or r , ' 

. 4 i • „• • i <r * ■ *■ a u that different compames store content such as employee 

digital printing, commercial offset printing, or flexography. , * . A .„ . * JL *• 

,, to ^- , , -j • * names and addresses m different ways. Other automation 

More particularly, the mvention provides various systems L . . , , . ,. . ■ ' , 

. , \_ . r * * j • 1 * barriers are inherent in the distributed and non-unirorm 

and techniques for usmg event-driven rules to initiate print- . ... . , . , , . , , 

, . , i A , & , . r , A . , r r process steps that are earned out by different print vendors 

production tasks on the basis ot data extracted from corpo- r , c* r iL t_i 

*\ , - , t and suppliers. Some of these problems are discussed in more 

rate systems or databases such as enterprise resource plan- 25 TTO r v XT nniA£nnn n 

3 A , * . detail in copending U.S. apphcation Ser. No. 09/460 ,307 

nine systems, human resource management systems, r ay J* ^ innn - . 4 "7, 

* J .'.. , ° t J now pending, filed on Dec. 13, 1999, and incorporated by 

manufacturing, logistics, or other corporate systems. * L • 

&7 & r ^ reference herein. 

BACKGROUND OF THE INVENTION 0ne approach for solving some of the foregoing problems 

30 is to use a centralized print production system that accepts 
Conventional techniques for generating customized pnrjt ordets over me Internet and allows the customer to 
printed products such as business cards, stationery, and other approve print proofs on-screen. As described in the above- 
personalized and marketing communication materials fre- referenced patent application, the printing process can be 
quently employ computers in the production process. In simplified by using certain file formats and data processing 
FIG. 1, for example, a customer 103 desiring to have ^ techniques to generate printed products. Nevertheless, fur- 
business cards printed for a new employee typically brings mer automation is possible. 

or faxes information 104 to a print broker 101, such as a Enterprise resource planning systems (ERPs) are conven- 

local print shop or copy store. An employee 106 creates an Uonally used to store> track md plan information concerning 

order for the print product using an ordering computer 105. ^ ente[pris6> sucn as a company. For example, many 

The print order may specify the number of cards to be 4o companies ^ hlim an resource management systems that 

produced, the font styles to be used, and customized content stQre i n f ormation sucn as employee names, addresses, titles, 

such as the employee's name, title, and telephone number. sa i ar i es , and the like. An example of one such system is a 

The print order created in ordering computer 105 can be commercially available product from PeopleSoft.™ Such 

transmitted to a second facility 102 for preprocessing. The systems typically perform payroll and accounting functions, 

order can be transmitted as an ASCII file over a communi- 45 and other human resource related functions such as organi- 

cation link 107 to a second computer 108 at the second zational management. Other enterprise resource planning 

facility. A layout computer 108, operated by another systems perform tasks such as tracking and planning sales, 

employee 109, is used to lay-out the content within the space manufacturing operations, and the like. Companies that do 

and style constraints of the printed medium (e.g., business not use ERPs may nevertheless store company-wide infor- 

cards of a certain size). Conventional software packages 50 ma uon in databases that allow the data to be accessed in a 

such as Pagemaker™ and Quark™ can be used to format the structured way. 

printed product and simulate its appearance before it is jhe aforementioned ERPs and databases have not typi- 

actually printed. ca U v been coupled to an automated printing facility of the 

The output of the layout computer, which may comprise type described above. Even though ERPs and related data- 

for example a PostScript™ file, is sent to an image setter 55 bases store extensive company-wide information such as 

110, which is a device that generates a plate or other medium employee data, organizational information, inventory and 

that can be directly used by a printing press 111 to produce manufacturing data, and the like, such ERPs and databases 

the printed product 112. Depending on the type of print have not been linked to an automated print production 

medium, the printed product may comprise customized process that could make direct use of the data stored therein, 

paper products, embossed materials, rubber stamps, plaques, ^ Instead, humans still manually generate print production 

or the like. Although the conventional arrangement shown in requests on the basis of changes to the company's data. 

FIG. 1 is exemplary, the system may be housed in a single Because corporate databases and ERPs have historically not 

facility, such that all of the printing tasks occur at a common been directly accessible to outside vendors, it has not been 

location. feasible to directly translate data stored in such databases 

Large corporations by their nature require large quantities 65 into print production requests, 

of customized printed products, such as business cards, sales When a new employee is added to a company's database, 

brochures, and letterhead. Each time a new employee joins a human resources manager must recognize that event, and 
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must manually create a print order for new business cards, The inventive principles have broad application to various 

name plaques, and Letterhead. This manual intervention types of corporate databases and ERPs. In a human 

provides opportunities for errors to creep into the print resources management system, print orders for new business 

production process, and introduces delays. (For example, if cards can be automatically generated whenever a new 

the human resources manager is out sick, busy, or on 5 employee is added or when an organizational change occurs, 

vacation, the order for business cards may be delayed). In a manufacturing environment, print orders can be auto- 

Moreover, the labor involved in generating such print orders matically generated when a new design is released for 

is costly, particularly where a company adds dozens of new production or when an order is placed that requires corre- 

employees on a weekly or monthly basis. sponding printed products. In a sales management system, 

As another example, suppose that a corporation decides to 30 customized sales brochures can be automatically printed in 

create award plaques, coffee mugs, and specially embossed response to entry of a new sales prospect. In an inventory 

pins for all sales employees who have exceeded a sales control system, print orders can be automatically generated 

quota. The job of creating print orders to generate such when inventory levels fall below a threshold, or after a 

printed products would typically fall to a human resources specified period of time has elapsed (e.g., print new bro- 

manager or similar employee, who would query the com- « enures every 90 days). In a publishing environment, reprint 

pany's database to identify such sales employees, generate orders for magazine articles and the like can be automati- 

a printout of employee information (e.g., name, title, and the cally generated in response to a reprint order request, or 

like), and manually create print orders for the various printed wnen tne number of reprints in stock falls below a certain 

products. That task is labor intensive and, as noted above, level. Other application areas are also possible, 

could result in misspelled names or other data errors. ™ brief DESCRIPTION OF THE DRAWINGS 

As yet another example, suppose that a bicycle manufac- 
turing company receives an order to manufacture 5,000 new FIG - 1 shows a conventional technique for generating a 
bicycles of a particular model and style. A manager at the printed product such as business cards, 
manufacturing company must determine when the bicycle FIG. 2 shows a system that monitors changes to a cor- 
order will be completed and, based on the schedule, create 25 porate database and executes rules that automatically gen- 
a print order to have printed instruction manuals, warranty erate printed products in response to such changes, 
cards, and the like generated in time to be included with the FIG. 3 shows a print production system that uses the 
manufactured bicycles and shipping boxes. Internet to communicate event data and obtain procurement 

approvals. 

FIG. 4 shows a centralized print production system that 

The present invention provides a system and method for detects events occurring at a plurality of companies, wherein 

extracting information from one or more corporate databases one company uses a corporate procurement system through 

and automatically generating print production orders using which print requisitions must be handled while another 

such information. In one embodiment, a set of event defi- 35 company does not use such a procurement system, 

nitions is provided based on changes to data in the corporate FIG. 5 shows a series of steps that can be carried out to 

database. Aset of event rules is also defined, such that a print implement a method in accordance with various aspects of 

production request or requisition is automatically generated the invention. 

in response to firing of one or more event rules. The print pig. 6 shows how fields in different corporate databases 

production request or requisition contains data directly 40 can be mapped to a common data element in a central print 

extracted from the corporate database, rather than being facility, and how certain fields can be mapped to locally 

manually entered by an employee. A notification can be stored data that is not stored in the corporate database, 

generated that confirms that the print order was automati- FIG. 7 shows one possible event rule that can be used to 

cally generated and indicates a date by which the print order specify various parameters such as stylej cost? delivery 

will be processed and shipped. 45 options> shipping destination, and notifications. 

According to other aspects of the invention, a computer FIG. 8 shows a system in which a plurality of corporate 

program monitors changes to one or more corporate data- databases ^thin a single company are monitored for 

bases and generates event data in response to such changes. ch and a lufa]it of cvcnt ^ arc defined tQ handk 

The event data is transmitted over the Internet to a central- event daU from each database< 

ized print production facility, where the event data is used to <n n , . A _ „ , . . , 

,™ Z m ™ ™u;„u ; n FIG * 9 shows a user interface for defining event rules 

tire one or more event rules, wnicn in turn automatically , A * 4 c . c .. . , • 

■ t Jt - j t relating to printing documents from information stored in a 

generate pnnt requisitions or print production orders. In one & v % iU wuumimmuiauuu^ivuiiia 

variation, print requisitions are routed through an existing numan '^rces database. 

and commercially available procurement system, such as FIG ' 10 shows a P rocess for Populating an event message 

Ariba™, before a print production order is generated. One 55 structurc - 

variation of the invention can monitor and handle event data FIG- U shows a user interface for defining event rules 

from multiple corporations, each having its own business- relating to printing documents from information stored in a 

related event rules, and each potentially having its own manufacturing database. 

procurement approval system. FIG. 12 shows a user interface for defining event rules 

Fields in print requisitions and orders can be mapped to 60 relating to printing documents from information stored in a 

corporate database schemas, such that different corporate sales management system database, 

identifiers for a particular data item (e.g., employee name) FIG. 13 shows a user interface for defining event rules 

are mapped to a common data item in the print production relating to printing documents from information stored in an 

facility. Moreover, some or all of a corporate database can be inventory control system database. 

mirrored at a central facility so that information for print 65 FIG. 14 shows a user interface for defining event rules 

requests can be extracted locally rather than generating relating to printing documents from information stored in a 

further queries in the corporate database. publishing system database. 
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FIG. 15 shows a user interface for defining production 
rules for printing. 

DETAILED DESCRIPTION OF THE 
INVENTION 

FIG. 2 shows a system that employs various principles of 
the present invention. As shown in FIG. 2, an event rule 
generator 201 is used to generate one or more event rules 
that are then stored into an event rules database 202. The 
term "event rule" will be used to refer to a rule that generates 
an action in response to a business-related event, such as the 
addition of a new employee to a corporation; a change in 
inventory levels for a product; or the receipt of an order to 
manufacture a product. Other rules based on parameters 
such as the passage of time could of course be defined. 
Although it is expected that different companies will have 
different event rules tailored for their particular business 
needs, it is of course possible to use the same set of rules for 
more than one company. 

According to the invention, event rules can be defined 
using any of various techniques such as a graphical user 
interface or a natural language tool. At least some of the 
rules may specify that one or more print production requests 
or requisitions is to be generated upon occurrence of a 
business event. An example of an event rule might be: IF 
(new-employee-added) THEN GENERATE 
(REQUISITION: business-cards USING new-employee- 
information). The nature and number of the rules will of 
course be dependent upon the type of business, the type of 
database, and the type of ERP used by the company. In 
general, however, it is expected that event rules cause, either 
alone or in combination with other rules, one or more print 
production requests to be generated using information per- 
taining to the event. 

The term "print requisition" will be used to refer to a print 
request for which further approval or information is required 
before the printing can be completed. The term "print 
production request" will be used to refer to a print request 
that can be executed without such intermediate approval or 
additional information. Print requisitions and print produc- 
tion requests may be referred generally herein as a "print 
order." 

The term "event" will be generally used to refer to a 
real-life event that can be detected (e.g., adding a new 
employee, or a change to an inventory level), while the term 
"event data" will be generally used to refer to information 
concerning an event that has occurred (e.g., the employee's 
name and other information). The term "event message" will 
be generally used to refer to event data that has been 
augmented with some additional information in order to 
generate a print requisition or print production request. 
These terms are not intended, however, to be limiting. 
Moreover, the invention can be practiced without using 
event messages altogether. 

Some event rules may not directly result in the generation 
of a print requisition or a print production request, but may 
instead set variables or store data into a database that causes 
other rules to fire. For example, a first rule could be defined 
that increments a new employee counter whenever a new 
employee is added, and a second rule could be defined that 
generates a new order for business cards whenever the 
number of new employees reaches five. 

Moreover, some events may cause other events to fire. For 
example, if an organizational unit of a company changes its 
name, then all employees belonging to that organizational 
unit may require new business cards. A rule can be con- 
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structed that automatically queries all employees in the new 
organizational unit and generates print requisitions for new 
business cards (using the new organizational name) for all 
such employees. 

The general creation and use of rules to perform further 
processing is conventional and can be implemented using 
well-known expert system techniques (e.g., PROLOG), for 
example. Customized rules could also be programmed 
directly in software using programming languages such as 
C, C++, Visual Basic, LISP, or the like. See U.S. Pat. No. 
5,893,911, entitled "Method for Defining and Applying 
Rules for Message Distribution for Transaction Processing 
in a Distributed Application," assigned to Neon Software 
Inc. Examples of various user interfaces that could be used 
for establishing business related event rules are provided 
herein. 

Returning to FIG. 2, it is assumed that a corporate 
database or ERP 203 contains information relating to a 
particular application area, such as human resources, inven- 
tory control, sales management, or the like. The database can 
comprise a relational or object-oriented database, and data 
residing in the database can be queried and modified using 
well-known data access conventions such as Structured 
Query Language (SQL). Any of various commercially avail- 
able databases such as Oracle, Sybase, or Informix could be 
used. It is of course possible that multiple databases co-exist 
on a single computer, or one or more databases can be 
distributed across different computers in a corporation. 

A computer-implemented monitoring function 204 moni- 
tors corporate database 203 for changes. Monitoring func- 
tion 204 can be configured to watch for changes to particular 
fields or tables in a corporate database (e.g., any change to 
employee records), or it can be configured to generate event 
data whenever any change occurs. When a new record is 
added to the database, monitor 204 extracts some or all of 
the new information ("event data") and transmits it to event 
manager function 205. For example, if a new employee is 
added to the database, monitor 204 extracts the new employ- 
ee's name, address, and other information, and transmits the 
event data event manager 205. Monitoring function 204 can 
be configured to periodically query the database for new 
records, or it can be configured to intercept database updates 
and generate event data in response thereto. Moreover, the 
monitoring function can be implemented on a separate 
computer coupled to a computer on which the corporate 
database resides, or it can by hosted on the same computer 
as the database. 

In some cases, subsidiary information may be required in 
order to create a print requisition or print production request, 
and other databases can be queried to create information 
sufficient to create a print requisition or print production 
request. For example, when a new employee is added to the 
database, the billing and shipping information for business 
cards to be printed for the new employee can be extracted 
from a different database. As another example, a particular 
company's graphics logo that is used on business cards may 
not reside in the corporate database 203, but may instead be 
stored in a different location. The subsidiary look-up func- 
tions could be performed by monitor 204, by event manager 
205 or by another software function. Such further informa- 
tion may exist on a corporate database or it may exist locally 
on a central print production server. 

Event manager 205 receives event data from monitor 204 
and, by executing rules stored in event rules database 202, 
generates a print requisition to a procurement system 206. In 
one embodiment, procurement system 206 comprises a 
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commercially available procurement product such as The rule can also specify a delivery constraint (e.g., must 

Ariba™, Concur™, or Commerce One™. Such systems be delivered within 3 days), which can be used by the 

provide facilities for creating and updating purchase orders software to locate a print vendor that is within a 3-day 

and obtaining approvals to release the orders to vendors. In shipping area of the shipping address (or is willing to ship 

other embodiments, a print production request is directly 5 on an expedited basis within that constraint). A shipping 

generated and provided to print production system 207 address can also be specified, and if necessary can be 

without going through a procurement system 206. queried from the corporate database or other location. 

One possible print production system 207 is described in Finally, a notification option can be specified in order to 

co-pending application Ser. No. 09/460,307, entitled "Sys- notify the employee and the human resources administrator 

tern and File Structure for Consistent Visual Medium 10 when the order is shipped. Other variations are of course 

Materials/' which is incorporated by reference herein. Print possible, and the example of FIG. 7 is not intended to be 

production system 207 may comprise a centrally located limiting. 

facility through which print orders can be received over the Turning now to FIG. 3, a system that incorporates various 

Internet from a plurality of companies. Imaging system 208 principles of the invention in an Internet environment (or 

and print processor 209 are conventional. Imaging system 15 similar network) will be described. It is assumed that a 

208 may comprise any of various types of devices that corporate database 301, a database monitoring function 302, 

generate print media such as printing plates or sheets on the and a corporate procurement system 306 is located at a 

basis of an electronic file, and print processor 209 performs company facility 350. Additionally, it is assumed that moni- 

the actual printing, embossing, engraving or the like in order toring function 302 and corporate procurement system 306 

to generate printed products 210. 20 are accessible through the Internet 307 using conventional 

In one embodiment, print production system 207 can protocols such as HTTP, FTP, and the like. Event manager 

transmit print orders to multiple vendors, such as Vendor A 304, event detection function 303, event rules database 305, 

and Vendor B shown in FIG. 2 . In this manner, different rules and mirrored database 312, along with the other functions on 

can specify that certain types of print production tasks are to the right side of FIG. 3, are assumed to reside at a centrally 

be routed to one geographic print location, while other types 2 s located P rint production facility 360 that is similarly acces- 

of print production tasks are to be routed to another geo- sible over the Internet 307. It will be appreciated that certain 

graphic print location. For example, if business cards are to of the functions can be centrally located, while others (e.g., 

be printed for a new employee at the California location of imaging system 309 and/or print processor 310) could be 

a company, the actual print job can be routed to a print located at a separate facility. 

vendor located in California, in order to minimize shipping 30 Database monitoring function 302 comprises software 
costs and expedite delivery. A print job for an employee that is tailored to the company's corporate database 301 to 
located in New Jersey might be routed to a New York City monitor changes to certain fields in corporate database 301 
vendor for the same purpose. In one embodiment, a software and, in response thereto, generate event data that is trans- 
function in print production facility 207 locates the print mitted over the Internet or other network to event detection 
vendor nearest to the shipping location. The print production 35 function 303 at the central print production facility 360. 
system can be coupled to different vendors over the Internet, Database monitoring function 302 may be implemented on 
by facsimile, or by other methods. a separate computer from corporate database 301, or it may 

Rules can be created to select vendors based upon other co -exist on the same computer. According to one 

criteria, such as ownership of the vendor or the business embodiment, database monitoring function 302 and event 

practices of the vendor, For example, some municipalities 40 detection function 303 use the commercially available Web- 

require that, in order to enter into a contract with the Methods Server software in order to extract and transmit 

municipality, an organization subcontract a percentage of information over the Internet. It will be appreciated that 

services to minority-owned businesses. Alternately, some instead of the Internet, other types of networks such as local 

organizations desire to only employ services from environ- area networks and the like can be used, 

mentally friendly companies. Accordingly, rules can be used 45 Event detection function 303 receives event data from 

to select vendors based upon ownership of the vendor or the monitoring function 302, converts each into an event mes- 

vendor's business practices. sage that forms the predicate for one or more rules in event 

More generally, rules can be used to specify various cost, rules database 305, and passes the event message to event 

schedule, delivery, location, print quality, shipping, and manager 304. Where necessary, database fields in corporate 

other parameters associated with print jobs. Turning briefly 50 database 301 are mapped to fields used internally by print 

to FIG. 7, a rule can be defined that is fired whenever a new production facility 360 to create printed products, and this 

employee is added to Company X's corporate database. The mapping can be done in monitoring function 302, event 

rule can specify that upon such an event, a print production detection function 303, or event manager 304. As explained 

request for new business cards be generated using a par- above, conversion of event data into an event message 

ticular pre-defined business card style for Company X. The 55 structure may require supplementation of data such as 

rule can also specify that the business card be generated billing information and the like, although such a step may 

using information regarding the new employee extracted not be required. Database monitor 302 and event detector 

from the event data (i.e., extracted from the corporate 303 can be located on either client side 350 or print facility 

database), wherein additional information such as billing side 360, depending on design requirements, 

information can be extracted from other data sources. 60 Turning briefly to FIG. 6, a first company (Company X) 

Moreover, the creator of the rule can specify that the cost might use a certain database schema that contains fields 

must be less than $20 for a set of business cards, thus identified as EMPLOYEE-NAME, EMPLOYEE-TITLE, 

causing print production system 207 to locate a print vendor and the like. A second company (Company Y) may refer to 

that can satisfy this requirement. Alternatively, rules can be similar data items in its database as ENAME, ETTTLE, and 

used to optimize multiple print production requests into a 65 so forth. Fields in different corporate schemas 601 and 603 

print job that can be routed to a vendor able to satisfy the can be mapped to a common schema 602 within print 

requirement. production facility 360, such that an instance of a field for 
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EMPLOYEE-NAME from Company X is stored into a new business cards). The procurement system recognizes 

generic NAME field in the print production facility, and an the request as one to be directed to a print vendor, and 

instance of a field for ENAME from Company Y is stored transmits the request to event manager 304 over the Internet, 

into the same named field in the print production facility. Event manager 304 fills in customer-specific details not 

Similarly, data that does not reside in either company's S included in the request, verifies the completeness and cor- 

database can be stored locally within print production facil- rectness of the resulting structure, and places the request in 

ity 360 in a separate database 604 having fields mapped to a queue for processing. 

the common schema 602. For example, a "logo" field that According to one variation of the invention, event queues 

refers to a graphical logo that is to be printed on a company's may b e used to temporarily hold event messages until 

business cards may be stored separately in a logo database 10 another specified event occurs (for example, the passage of 

604 at the print production facility. References to each a per i 0 d 0 f time). Queues can be used on the client or 

company's logo as part of a print order will cause the logo corporate side 350 of the system of FIG. 3 (e.g., in connec- 

to be retrieved locally from database 604. ii on with database monitor 302), or they may be placed on 

Returning to FIG. 3, in one embodiment event manager the print production facility side 360 of FIG. 3. For example, 

304 executes event rules and, in response thereto, generates 15 event messages can be queued until the end of a business 
a print production request to print production system 308. In day, or until a specified number of events (e.g., ten or more 
another embodiment, event manager 304 executes a rule that events) have occurred. Additionally, events can be condi- 
causes a print requisition in the form of a procurement order tioned on the occurrence of other events. 

to be generated and sent to corporate procurement system \ t De appreciated that the various functions illustrated 

306 for approval. Such a request can be sent over the 20 m FIG. 3 can be located on the client side (350) instead of 

Internet, and approval returned in the same manner. After a t a central print production facility (360), and that various 

receiving approval, a print production request is generated functions may be combined for purposes of design and 

and passed to print production system 308 for execution. efficiency. Consequently, the architecture shown in FIG. 3 is 

Event manager 304 can also automatically notify a corporate intended to be exemplary only. For example, at a portion of 

employee (e.g., via e-mail) to confirm that the order was 25 the event detection function may be combined with the 

placed. The latter notification can include an estimated database monitor 302 on the client side 350. This allocation 

completion and shipment date for the order. 0 f function would help reduce the number of actions to be 

Event manager 304 can be implemented as a queue-driven handled by event detection function 303 and event manager 

process that retrieves a next event from the queue; retrieves 304. In this instance, the database monitor 302 could store 

any business rules that apply to that event, and performs the 30 event rules and include a queue that stores database actions 

actions that apply to that event. Different sets of event rules until an event is to be generated. 

for different companies can be stored in event rules database FIG. 4 shows an alternate embodiment in which a plu- 

305 and retrieved according to the company from which an rality of companies 401 and 402 are coupled to a print 
event was generated. Moreover, event manager 304 may ^ production facility 406 through the Internet, and wherein a 
generate additional events based on the firing of certain first company 401 uses a corporate procurement system 403 
rules. For example, if an organizational change occurs, a rule for approval of print requisitions, while a second company 
can be fired that automatically queries all employees 402 does not use such a procurement system. This embodi- 
affected by the organizational change and generates a print me nt illustrates how a central print production facility 406 
requisition for each new employee to create new business can handle different types of requirements from different 
cards for those employees. In certain embodiments, it may companies. 

also be possible to pass event data directly to event manager FIG 5 shows steps that can be carried Qu{ to ^p^nt 

304 without processing by event detection function 303. various mcthods of me invention. Beginning in step 501, one 

In one embodiment, a mirrored database 312 is main- or more printed products are defined, and the data content 

tained at the central print production facility 360, such that 45 required for each product is mapped to one or more fields at 

database changes in corporate database 301 are transmitted the print production facility. For example, a business card 

to mirrored database 312. When additional information is product may comprise various common fields such as name, 

needed for a print request, it can be extracted directly from title, address, telephone number, corporate logo, and the 

mirrored database 312 instead of querying corporate data- like. Additionally, certain formatting information such as the 

base 301. In yet another variation, monitoring function 313 50 s i zej shape, color, and other parameters of the business card 

can be located at the print production facility and used to are specified. This information collectively defines one type 

monitor changes to mirrored database 312 instead of hosting 0 f printed product (e.g., business card type A). Step 501 may 

such monitoring functions at the corporate facility. In this be performed with respect to a user interface as shown, for 

case, some mechanism for maintaining synchronization example, in FIG. 15. 

between the databases would be needed (e.g., periodic batch ss In step 502, events that can occur in the system are defined 

updates or the like), as is known in the art. anc j map ped to one or more corporate database fields. For 

Certain types of print requisitions may require additional example, an event message NEW-EMPLOYEE-ADDED 

information, such as a billing or shipping address for the can be defined to occur when a new employee record is 

print production request. This additional information can be added to the corporate database, and various fields from that 

extracted from corporate database 301, from mirrored data- $q record are mapped to corresponding fields in the print 

base 312, from a local database maintained at the print production facility (see FIG. 6). Some rules can be created 

production facility 360, or provided by corporate procure- such that they are triggered automatically upon passage of a 

ment system 306. certain quantity of time (e.g., check an inventory level every 

In one embodiment, print requests are generated when an 5 days, or print a new catalog once a year based on the 

external procurement request is generated. According to this 65 current state of a parts database). 

embodiment, a company employee uses a commercially In step 503, company-specific event rules and correspond- 

available procurement system to request a print job (e.g., ing actions are defined. As one example, when a new 
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employee record is added to the corporate database, a print 
requisition for 1,000 business cards, a new name plaque, and 
customized letterhead for that employee will be automati- 
cally generated, using data extracted from the corporate 
database (i.e., without human input). If the employee is a 5 
sales employee, then sales brochures or other pertinent 
printed products can be generated. 

As a further example, a company may have a specific 
business rule that states that if a sales person exceeds bis or 
her sales quota for a given quarter, that salesperson may 10 
order a special set of business cards and stationery items. In 
this example, events can be defined (step 502) such that once 
an individual sales quota is exceeded, two actions will be 
performed by step 504. One action may be to grant ordering 
privileges to the special product set, and the second action 15 
may be to send a notification to the salesperson informing 
them of their ability to order these products. This example 
does not exclude the possibility that a print production 
request could be generated directly (step 507). 

As another example, if a new product order is added to the 20 
database, a print requisition for a number of printed products 
(instruction books, warranty cards, and the like) correspond- 
ing to the number of products ordered will be automatically 
generated. Again, it is preferred that no human manually 
enter information such as numbers or product codes in order 25 
to generate the print request, in order to minimize human 
intervention and avoid data entry errors. 

Step 503 may also include interacting with a user inter- 
face. The user interface may take the form of displays on a 3Q 
screen similar to those shown in FIGS. 9, U, 12, 13, and 14. 
After interacting with the user interface, the event rules may 
be saved into event rules database 202. 

Rules can be defined to perform any of various actions 
when triggered by an event. 35 
Some examples include: 

(1) Send an e-mail regarding notification or scheduling of 
a future event; 

(2) Create, cancel, or approve a purchase order; or update 

a database record in a central print production facility 40 
(including checkpointing or taking a snapshot of a 
corporate database); 

(3) Perform an external procurement operation (e.g., 
through a commercial system) 

(4) Perform an action on an external customer corporate 
data (e.g., update an employee record, update an inven- 
tory record, or insert a purchase order number); 

(5) Perform an action on a print vendor's system (e.g., add 
job, cancel job, etc.); 50 

(6) Perform an action on an external manufacturing 
tracking system, such as HAGAN™ (e.g., create a job 
in process, update job in process, etc.). 

An automatic procurement action can be initiated based 
on detection of an event. For example, if a new employee is 55 
added to the corporate database, a procurement order can be 
automatically generated to request that a certain predeter- 
mined set of personalized office supplies such as letterhead, 
envelopes, business cards, and the like be ordered and 
shipped to the new employee's address. 6Q 

In step 504, events in the system are detected and rules 
fired based on changes to the corporate database. 
Alternatively, event messages may be generated in response 
to a manually entered procurement order. 

In step 505, a print requisition is optionally generated 65 
using data extracted from the corporate database and, if 
necessary, from other sources (e.g., logo image files; billing 



45 



and shipping addresses). As explained above, requisitions 
could be avoided and print production requests directly 
generated in certain embodiments of the invention. If a print 
requisition is generated, then in step 506 approval of the 
requisition occurs, either through a commercially available 
procurement system or some other mechanism. 

In step 507, a print production request is generated, again 
preferably using information extracted from the corporate 
database rather than manually entered information. 
Additionally, a notification feature can be provided, such 
that an e-mail message is transmitted to a predetermined 
employee (or to the employee whose print products were 
automatically ordered) confirming that the print order was 
submitted, and providing an estimated completion and/or 
shipping date. 

In one embodiment, a notification or shipment request can 
also be generated for a vendor to schedule further action on 
a particular date. For example, if it is determined that the 
print job will be completed in two days and result in a certain 
quantity of paper products, an advance notification can be 
transmitted to a shipping vendor to schedule pick-up of a 
predetermined number of boxes on the date that the print job 
will be completed. 

Finally, in step 508 the printed products are generated. 
These may comprise paper products, plaques, embossed 
items, packages, container labels, and the like. 

FIG. 8 shows a system in which a plurality of different 
types of corporate databases, such as human resources 
database 803, sales database 804, and manufacturing data- 
base 805, are monitored in order to generate event data to an 
event detection function 809. Event detection function 809 
generates event messages that are handled by event manager 
810, which applies separate rules tailored for each type of 
database. For example, one set of human resource rules 806 
may apply only to events occurring in the human resources 
database 803, while sales rules 807 pertain only to events 
arising from sales database 804 and manufacturing rules 
apply only to events occurring in manufacturing database 
805. Although separate monitoring functions are shown in 
FIG. 8 to allow for the possibility that the databases may 
reside on different machines at different locations, the moni- 
toring functions and databases could of course be combined 
into a single machine at one or more locations. 

A more detailed description of one possible approach for 
allowing a user to define various types of event rules in the 
system will now be provided with reference to FIGS. 9 
through 16. Various user interface techniques, such as form- 
driven web pages, can be used to accept user input to define 
event rules. As discussed above, rules can also be specified 
in a declarative language such as PROLOG or the like and 
executed by an inference engine. Combinations of the two 
are also possible, such that a browser-based form input tool 
is used to generate declarative rules, which are then inter- 
preted by an expert system or inference engine. 

Referring to FIG. 9, a user interface is shown for receiving 
input relating to designation of event rules. The user inter- 
face includes a first selection 901 in which a user designates 
the type of printed product to be generated. A second 
selection 902 allows the user to designate when an action or 
event will trigger the rule, and includes a pull-down menu 
903 that specifies various types of events that can occur in 
the database to which the rule pertains. According to one 
embodiment, the events correspond to changes to pre- 
defined columns in a database table (e.g., new employee, 
changed telephone number, and the like). 

Option 904 allows the user to specify when the print 
production job should be released, and may include a variety 
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of options 905, 906, and 907. For example, as indicated at 
905, the print job can be released automatically, so that the 
printing is initiated immediately after detection of the event. 
Alternatively, the print job release may be conditioned on 
various factors such as whether an optimum number of print 5 
jobs has been received in a queue (optimum in the sense that 
multiple print jobs can be combined for efficiency); whether 
a certain number of print requests has been received; or 
whether a certain number of days has elapsed. 

An optimum number of print jobs may relate to specific 10 
conditions of the printing production system 308 of FIG. 3. 
For example, as is known in the art, business cards are 
generally printed in batches consisting of groups of four, six, 
eight, etc. cards each. A printer attempts to minimize set up 
and break down costs for a printing press by placing as many 15 
different cards on each printing plate or die as possible. By 
increasing the number of cards on the plate or die, the longer 
the run length of the printing press. Because setting up and 
breaking down a press run involves certain fixed costs, 
overall costs can be minimized by spreading the fixed costs 20 
over as many printing jobs as possible. The ability for the 
client to specify that the rule is only to be fired when there 
are an optimum number of print jobs thus may reduce costs 
to the client. 

Finally, user interface portion 906 allows for a default 25 
release after a selected number of days. If a queue resident 
on event manager 304 contains actions that are older than a 
specified number of days, the queue will be flushed and the 
event manager 304 will initiate the print production requests 
for items in the queue. 30 

User interface selection 907 allows a user to designate 
that the job will need to be approved prior to releasing the 
job. In this situation, the user would enter the information 
regarding who will provide approval. In some cases, mul 1 
tiple approvals may be required. Where at least one person 35 
or process has been designated to approve a job, the occur- 
rence of an action satisfying the criterion of 903 instructs 
event manger 304 to generate a request for approval from 
corporate procurement system 306. In an alternative 
embodiment, corporate database 301 can be updated with an 40 
indication that approval has been sought, thus causing 
database monitor 302 to monitor corporate database 301 for 
an indication that the print job has been approved. At that 
point, database monitor 302 would transmit an approval 
action to event detection 303, which would then generate an 45 
approval event for handling by event manager 304. 

Selection option 908 allows the user to specify shipping 
information (e.g., ship when order complete, hold until a 
designated time, and ship to a designed entity). Option 909 
includes a button for saving the entered information. It is 50 
appreciated that additional screens may be used to input 
information and the actual saving of information can only 
occur after all information has been entered. 

FIG. 10 shows an example of a process for populating an 
event structure. In FIG, 10, an employee record is updated 55 
(step 1001). The change in the database storing the 
employee record is detected (step 1002). An event structure 
(reporting the change) is populated (step 1003) with infor- 
mation regarding the change as detected in step 1002. In the 
situation where certain additional information (not supplied 60 
with the detected change) is needed, such additional infor- 
mation is retrieved in step 1005 and populated into the event 
structure (step 1004). Alternatively, the additional popula- 
tion steps could be performed on the print production system 
side 360. 65 

In step 1006, the event structure is checked for complete- 
ness and correctness. If additional information is needed to 
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fulfill the print request (for example, the specific corporate 
logo or template to use), this information is retrieved from 
database 312 (step 1006) and the completed order placed in 
an event production queue for processing (step 1007). 

FIG. 11 shows a user interface for defining event rules 
relating to printing documents from information stored in a 
manufacturing database in accordance with embodiments of 
the present invention. Like the interface of FIG. 10, a first 
selection item 1101 allows a user to specify what printed 
product is to be generated when the rule fires. Interface 
portion 1102 allows a user to determine when the selected 
item in 1101 is to be printed. In some embodiments, at least 
two different situations are possible: the time that a design 
is released by one or more entities; and the time that a new 
product order has been placed. Selection option 1103 allows 
the user to select the product for which the item to be 
printed. 

FIG. 12 shows a user interface for defining event rules 
relating to printing documents from information stored in a 
sales management system database. Selection option 1201 
relates to the type of sales product to be generated (for 
example, sales packet no. 1, sales packet no. 2, etc.). 
Selection item 1202 allows the user to identify the event that 
will trigger the rule (for example, new contact added to 
database, new status of contact moving to level 2, new status 
of contact moving to level 3, and the like). Selection option 
1203 allows the user to specify where the printed product 
should be shipped. For example, the printed information 
may be shipped to the salesperson or the contact. 

FIG. 13 shows a user interface for defining event rules 
relating to printing documents from information stored in a 
inventory control system database. User interface portion 
1301 includes the type of item to be printed (for example, a 
flyer, a brochure, etc.). As database monitor 302 fires actions 
to event manager 304 through event detection 303, interface 
portions 1302 and 1303 indicate when an event has occurred 
for print processing. Interface portion 1402 allows a user to 
specify that an event has occurred when inventory falls 
below an adjustable number. In this example, database 
monitor 302 monitors the inventory in corporate database 
301 and forwards inventory changes to event manager 304 
through event detection function 303. Selection option 1303 
allows the user to specify that the printed product should be 
generated according to a specified time interval, 

FIG. 14 shows a user interface for defining event rules 
relating to printing documents from information stored in a 
publishing system database. User interface portion 1401 
allows the user to select the type of item to be printed 
(reprints, covers for magazines, etc.). Interface portion 1402 
allows the user to specify that a print order should be 
generated when the number of orders for a given item 
exceed a specified number. This could be beneficial when 
the set up costs for producing a small number of reprints is 
relatively high per reprint. By setting a minimum number of 
orders to be placed before executing the reprint order, the set 
up costs may be spread over a larger number of orders. 
Interface portion 1403 allows for the flushing of an order 
queue after a given number of weeks. For example, if a 
publishing house needs to complete all orders by a given 
time, all orders may be processed at a chosen time as 
specified in interface portion 1403. Interface portion 1404 
allows selection of the title to be printed. The selection of the 
title may also include selection of a portion of the title as 
well. For example, one may specify to reprint an entire 
magazine. Alternatively, one may separately specify to 
reprint selected articles for the magazine. Finally, interface 
portion 1405 allows for the user to select a specified overrun 



05/24/2004, EAST Version: 1.4.1 



US 6,473 : 

15 

to allow for any subsequent orders. A percentage overrun 
may be beneficial where the publisher knows that subse- 
quent orders may likely be received, but wants to create a 
stockpile of reprints at a given time (for example, prior to 
receiving all orders). This allows the publisher to not have 5 
to reset presses for running a short reprint run. 

FIG. 15 shows a user interface for defining production 
rules for printing. User interface portion 1501 allows the 
user to select a specified product. These production rules 
may also include designation of the customer (for example, 10 
company X as opposed to company Y). Sub designations 
may also be made for various individuals in the company 
through interface portion 1502. Interface portion allows for 
selection of the media type for the printing of the item 
selected in interface portion 1501 . For example, for business 15 
cards selected in interface portion 1501, the customer may 
wish to have one card stock for management and a different 
card stock for sales personnel. Interface portion 1504 allows 
for different templates to be specified. Interface portion 1505 
allows a user to specify which logo to use for a given printed 20 
item (for example, if a blue logo is to be used for sales v. a 
gold-embossed logo for management). Interface portion 
1506 allows for reporting (and approval, if specified, in 
interface portion 1508) to be made to various entities of a 
client. Interface portion 1507 allows for selection of a 25 
client's database that holds additional information. For 
example, a client may wish to maintain all content image 
files for printing. If the image file was not forwarded with the 
event as reported to event manager 304 and if the client 
maintains the actual image file, user interface portion 1507 30 
allows the specification of the database. Also, for secure 
environments, the interface portion may include authentica- 
tion and verification information 1507 needed to access the 
client's database. Interface portion 1508 receives user input 
to hold a print order until approval has been received from 35 
another entity. Finally, interface portion 1509 allows a user 
to select a printer based on some criteria. For example, a 
printer may be selected by location (close to a specified zip 
code) or chosen by ownership (e.g. jobs may be earmarked 
for printing by minority-owned businesses). 40 

The principles of the invention can be applied to not only 
traditional paper printed products, but to electronic docu- 
ments as well. For example, the invention can be applied to 
publish electronic documents and "deliver" them to Internet 
web pages, discussion groups, e-mail systems, collaboration 45 
portals, and to enterprise systems. All of the foregoing 
would be examples of database-driven means for commu- 
nicating and publishing digital information. 

Thus has been described various systems, methods and 
techniques for generating print production requests accord- 50 
ing to events that occur in a corporate database. Any of the 
method steps described herein can be implemented in com- 
puter software that is stored on a computer-readable medium 
such as a magnetic disk or CD-ROM. Many variations and 
alterations of the invention are of course possible. 55 
Consequently, the invention should be limited only by the 
appended claims and their equivalents. 

What is claimed is: 

1. A computer-readable medium having computer execut- 
able instructions for performing steps comprising: 60 

receiving a first portion of a print requisition or print 
production request from a print production system, the 
first portion relating to a client of the print production 
system; 
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receiving a second portion of the print requisition or print 
production request from the client of the print produc- 
tion system; and 
automatically combining, without human intervention, 
the first portion and the second portion into a format for 
the print requisition or print production request that is 
printable by a printing vendor. 

2. The computer-readable medium of claim 1, wherein the 
instructions include instructions for 

receiving the first portion from a storage device main- 
tained by the print production system; and 
receiving the second portion via a network communica- 
tion. 

3. The computer-readable medium of claim 2, wherein the 
network communication is an Internet communication. 

4. The computer- readable medium of claim 1, further 
including instructions for notifying the client after the first 
portion and the second portion have been automatically 
combined, 

5. The computer-readable medium of claim 1, further 
including instructions for sending the printable format for 
the print requisition or print production request to the 
printing vendor. 

6. The computer-readable medium of claim 5, further 
including instructions for receiving approval of the printable 
format from the client, and sending the printable format to 
the printing vendor in response to the approval from the 
client. 

7. The computer-readable medium of claim 6, wherein the r 
instructions include instructions for selecting the printing 
vendor based upon criteria designated by the client. 

8. The computer-readable medium of claim 5, wherein the 
instructions include instructions for selecting the printing 
vendor based upon criteria designated by the client. 

9. The computer-readable medium of claim 1, wherein the 
instructions include instructions for automatically combin- 
ing the first portion and the second portion based upon at 
least one event rule. 

10. The computer-readable medium of claim 9, wherein at 
least one event rule is previously designated by the client. 

U. The computer-readable medium of claim 1, wherein 
the second portion is specific to the client. 

12. The computer- readable medium of claim 1, wherein 
the instructions include instructions for receiving the second 
portion from an enterprise resource planning system main- 
tained by the client. 

13. The computer-readable medium of claim 12, wherein 
the instructions include instructions for receiving the second 
portion in response to a change of data in the enterprise 
resource planning system. 

14. The computer- readable medium of claim 12, further 
including instructions for 

receiving a third portion of the print requisition or print 
production request from a second enterprise resource 
planning system maintained by the client, and 
automatically combining, without human intervention, 
the first portion, the second portion and the third 
portion into a format for the print requisition or print 
production request that is printable by a printing ven- 
dor. 

***** 
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